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MAPPING A TRANSPORT STREAM INTO IP PACKETS 
FOR WLAN BROADCASTING SERVICES 

As a new application using a Wireless LAN (WLAN) in a hot spot (hotel lobby, 
airport, shopping mall, cafe, etc), wirelessly broadcasting live TV programs to WLAN- 
enabled mobile devices is attractive to many medium providers, such as FOX, NBC, 
ABC and CBS. Currently, in those high-volume traffic hot spots, a TV set tunes to a pre- 
set channel (e.g. CNN in an airport) and viewers have no choice of selecting different 
programs no matter he/she likes the program or not. With the WLAN deployment and 
WLAN-enabled devices, wirelessly broadcasting a number of TV programs in such a hot 
spot to those WLAN-enabled devices is a cost-effective way to attract a larger number of 
eyeballs for the medium companies. On the other hand, a viewer has his/her own private 
viewing environment, rather than watching a common TV program with everyone else. 

Currently, the TV broadcasting studios broadcast TV programs in digitally 
compressed MPEG-2 streams. Those streams are packetized into MPEG-2 Transport 
Streams (TS) for distribution over a satellite network. When those streams are received at 
hot spots and re-broadcasted over an IP based WLAN, mapping from the transport stream 
to IP packets must be performed. 

This invention proposes a unique mapping from an MPEG-2 TS into IP protocols to 
serve TP based MPEG-2 broadcasting services. 

An MPEG 2 transport stream comprises a set of multiplexed compressed audiovisual 
programs as well as related program information about these carried programs. Such 
MPEG2 transport streams are broadcasted in satellite, terrestrial, and cable networks. The 
receiver (e.g. a set top box) receives the entire transport stream (several programs), 
demultiplexes it, decodes and displays a particular audiovisual program according to the 
user choice. 

The solution of broadcasting an MPEG2 stream in an Ethernet LAN is to simply carry 
the MPEG2 transport stream packets over the UDP and IP multicast/broadcast protocols. 
This method requires a significant amount of processing power in the terminal to 
demultiplex the MPEG2 transport stream. In the context of WLAN where the terminal is 
a mobile device, such as a PDA or cellular phone, power consumption and CPU 
processing power are very critical to do all the processing. 

This invention proposes a novel MPEG-2 transport stream distribution method over 
an IP network, especially a WLAN. It relies on a pre-processing, including demultiplxing 
and mapping, of MPEG2 transport stream before distribution in a wireless network in 
such a way a terminal needs to listen to and process only the packets relative to the 
program the user is interested in. In addition the invention proposes several possibilities 
to reduce the amount of bandwidth that would have been required to transmit the original 
MPEG2 transport stream. Furthermore, the fact that the MPEG2 transport stream is 
demultiplexed in the network allows the possibility to transcode the MPEG2 program 
streams with the different bit rate requirements. 
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Kev Aspects of the Invention: 

1 . Method and apparatus for demultiplexing a composite MPEG transport stream 
into elementary streams, extracting the program related information and 
repackaging the program information into a well known multicasting IP address 
for consumption in a closed IP network. 

2. Mapping the aforementioned elementary(audio and video pairs) streams into a 
multicasting IP transport 

IETF RFC 2250 

[ 1 ] specifies a scheme to carry an MPEG-2 TS in RTP payload. In this scheme, a RTP 
payload contains an integral number of MPEG-2 transport packets, each with 188-byte 
length. This scheme relies on the receiver to do all the MPEG-2 TS processing, including 
de-multiplexing, extracting program information from PAT and PMTs, and forming 
elementary streams (ES) of programs from multiple transport packets. This scheme not 
only requires significant processing power in a receiver, but also reduces the channel 
bandwidth requirement to deliver MPEG-2 TS over a RTP/UDP/1P stack for broadcasting 
services. 

Introduction 

Mapping an MPEG-2 TS into IP packets for video broadcasting service requires 
special consideration of the characteristics of aTS. MPEG-2 TS protocol was designed to 
carry digitally compressed video over a Constant Delayed Network (CDN), such as cable 
or satellite networks. In addition to the audio and video contents in an Elementary Stream 
format, extra information about the underlying programs is carried in a TS as well to ease 
the receiver to select a desired program. Such extra information is called Program 
Specific Information (PST), including Program Association Table (PAT), Conditional 
Access Table (CAT), Program Map Tables (PMTs), identified by designated Packet 
Identifiers (PIDs). When mapping from an MPEG-2 TS into IP packets for broadcasting 
services, one must take special care about the extra information on the programs: 

• They must be carried over a well-known IP address and port, and therefore all 
the hosts in that subnetwork can receive them without pre-configuration; 

• They have to be transmitted at certain minimum interval so that a receiver can 
capture the program information so quickly that it can tune to a program 
without noticeable delay; 

• They have to be transmitted using as little channel bandwidth as possible to 
conserve the bandwidth. 

The last two requirements are contradictory to each other. A trade-off design must 
balance those goals in a systematic way. 

In an IP based network, Real Time Protocol (RTP) over UDP/IP is used to 
encapsulate video or audio packets. This RTP/UDP/EP protocol stack has many features 
embedded in those protocol headers similar to the features in an MPEG-2 transport 
stream. We examine and compare MPEG-2 TS with RTP/UDP/IP stack to find the 
mapping to achieve the following two goals: 

• The network under consideration is a WLAN with limited channel capacity. 
Reduce the overhead and minimize the bandwidth is essential; 
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• A WLAN-enabled receiver usually has limited CPU and memory resources. 
Simplifying the processing of an incoming video/audio stream in such a 
receiver is a key requirement for PDA and cellular phone devices to be able to 
run such a broadcasting application in real-time. 

This invention proposes to do as much pre-processing in the transmitter side as possible 

to reach those goals. 

A Wireless Video Broadcast Network System 

Figure 1 illustrates a basic video broadcast service system using a WLAN 
network. The MPEG2 source may be a local multimedia server or a digital signal 
received from a satellite transponder. The MPEG2 source can be an MPEG2 transport 
stream or a program stream. 



[VfPKC.2 Transuort Stream 

In a terrestrial broadcasting system, MPEG-2 Transport Stream (TS) carries 
audiovisual contents in fixed-sized packets. Figure 2 shows the process of generating an 
MPEG-2 TS from uncompressed video and audio. A program consists of at least one 
elementary video and one elementary audio stream. Multiple video (different viewing 
perspective) and audio (different languages) elementary streams in a program is 
permissible. All the packetized elementary streams of several programs and the Program 
Specific Information (PSI), including Program Association Table (PAT), Program Map 
Table (PMT), Network Information Table (NIT) and Conditional Access Table (CAT), 
are multiplexed into a transport stream. Each transport packet belongs to a particular 
elementary stream (either a video, audio or PSI). The packet identifier (PID) is used to 
address each corresponding elementary stream. This process is illustrated in Figure 2. 




PDA 



Figure 1: A video broadcast system over a wireless network. 
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Figure 2. Process of generating an MPEG-2 transport stream from uncompressed video and audio 
data. 



The MPEG2 Program Specific Information (PSI) is composed of different tables 
that provide information about the programs transported in the Transport Stream. Figure 
3 illustrates the hierarchical relationship between the PAT (Program Association Table), 
the PMTs (Program Map Tables) and the programs that a TS carries. A PAT is always 
identified by PID=0. In a PAT, all the programs are listed and each program is referenced 
by a PMT whose PID is associated with the program in the PAT. 
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In a proposed WLAN broadcasting system (see Figure 1), Multiple TV programs carried in an 
MPEG-2 TS is rc-broadcasted to all the WLAN-enabled devices within a WLAN coverage area. 
From a satellite transponder, a receiver receives an MPEG-2 transport stream consisting of fixed- 
sized transport packets. As suggested in 

[ 1 ], those transport packets can be directly encapsulated into an RTP pay load 
and carried over an IP-based WLAN. This approach has the following drawbacks: 

• It relies on the receivers to process (de-multiplex) the transport stream. For mobile 
terminals, the CPU power is limited and should be dedicated to other important tasks, 
such as video and audio decoding and displaying. 

• All the transport packets will be carried over in RTP payload, whether the receivers 
require them or not. This wastes precious bandwidth in a WLAN. 

• All the video or audio transport packets are encapsulated in a RTP traffic flow with 
the same destination address and port number. The receivers have to process all the 
RTP traffic with the TS payload even most packets are dropped on the floor. 

• There are some redundancy information carried in both transport packet and RTP 
headers 

In this invention, we propose a novel mapping from an MPEG-2 TS to IP-based 
RTP/UDP/IP stack for broadcasting service in a WLAN to achieve the aforementioned 
goals. All the mapping functions may be performed in the transcoder shown in Figure 1. 

Considering a mobile device (PDA) that is a thin-client-like host with limited CPU 
and memory resources, we should move as much of the processing function from a client 
to the server as possible, such as de-multiplexer function. When a transcoder receives a 
transport stream, it de-multiplexes the stream based on PIDs assigned to each transport 
packet. This de-multiplexing function extracts several components from a transport 
stream: video and audio PES/ES associated with programs and PSI (PAT and PMTs). 
The broadcasting service in a hot spot which could be free of charge for the subscribers 
or have a subscription model. The conditional access system is then simply the access 
control mechanism used in the communication layer. Encryption/Reencryption of content 
is not envisioned. Therefore, the conditional access table (CAT) in an MPEG-2 TS is 
ignored in the processing. Notice that not all the programs received from a transponder 
are to be rebroadcasted in a WLAN broadcasting service. Those undesired elementary 
streams are discarded in the processing to reducing the processing time and the WLAN 
bandwidth. 

Having de-muxed and re-assembled the PSI and all the elementary streams Tor 
WLAN broadcasting service, the transcoder maps each broadcasting elementary stream 
of a program into a RTP traffic data flow. The RTP packets are encapsulated in 
multicasting addresses (e.g. Class D IP addresses) and then transmitted over a WLAN. 
The multicasting addresses used to carry the elementary streams are announced by the 
PSI packets. 

When MPEG-2 video and audio elementary streams of a program are carried in a RTP payload, 
video and audio may be encapsulated into separate RTP traffic flows with distinct RTP payload 
types 

[ 1 ]-. This encapsulation of separating video and audio requires a receiver 
synchronizes video and audio for lip synch. Another encapsulation [3] proposes a 
bundled video and audio elementary streams belonging to the same program into a single 
RTP traffic flow for multicasting. This bundled encapsulation provides a coherent 
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synchronization between video and audio. This bundled encapsulation of video and audio 
in a single RTP traffic flow is preferred. 

To ensure that all the hosts connecting to the broadcast access point to receive the PSI 
for program selection, the PSI must be sent to clients along with the audiovisual streams 
to aid user to choose broadcasting programs. There are two approaches to do that. The 
first approach directly maps PSI tables in their original formats (PAT and PMTs with 
some modifications) into a well-known multicast address. Due to the different addressing 
schemes used in MPEG-2 TS and IP network, the transcoder must insert the multicasting 
IP address for each program in its associated PMT. In a PMT, only PIDs are used to point 
to its associated video and audio elementary stream. When a multicasting IP address is 
inserted into a PMT, additional byte space is required to store the IP address. The 
descriptor field in a PMT [2] can be used to store and carry the multicasting IP address. 
After the insertion of the multicasting IP address in a PMT, the CRC in the PMT must be 
re-calculated due to the modification of the PMT. The PAT and the PMTs information 
are processed to form the new program specific information (PSI) packets carried over 
UDP/IP using a well-known multicast address. The second approach is to define new PSI 
protocol suitable for a WLAN based video broadcasting service. The PSI protocol is 
carried over the same well-known multicast address and delivered to all the hosts within 
WLAN coverage area. The second approach provides a means to support some 
proprietary data in the PSI. In either approach, the packets carrying the PSI are called PST 
packets to distinguish them from the packets carrying the elementary streams. 

To reduce the receiver processing time when such program information remains the 
same (no changes in PAT and PMTs), a reserved bit in a PSI packet may be borrowed as 
a new flag to indicate that all the PSI remains the same or not since the last transmission. 
If any changes occur since the last transmission, the new flag is set (=1). Otherwise, the 
new flag is reset (=0). The entire processing is depicted in Figure 4. In that figure, the PSI 
table direct mapping and bundled RTP encapsulation approaches are illustrated. 
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Figure 4. The demuxing and encapsulating processing in the transcodcr. 

Client software in a mobile device first processes the PSI packets encapsulated in the 
well-known broadcast address to restore the program specific information stream in order 
to compose a program map, including the list of elementary streams for each program 
and their corresponding multicast addresses. The client may ignore the subsequent PSI 
packets as long as the new Hag remains reset. The program map must be re-bmlt in a 
client once the new flag is set in a received PSI packet. When a user requests to view a 
program, the client extracts the multicasting IP address from the program map and then 
only listens to the IP packets destined to that multicasting IP address. When a user 
switches to a different program (like a user change viewing channel on a TV), the client 
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software first locates the associated program information from the program map, extracts 
the multicasting address(es) associated with that program and listens to the packets 
destined to the selected multicasting address(es). This way, the client software can select 
various programs by listening to different multicasting addresses. 

In our proposed mapping, transport packet (TP) headers are eliminated during the 
mapping due to the redundant fields specified both in the TP header and RTP header. In a 
TP header, the relevant fields for a broadcasting is continuity _counter and Program Clock 
Reference (PCR) (PCR is inserted in an adaptation field of a TP header and the 
adaptation filed is optional for a TP.) The continuity _counter is used for a receiver to 
detect any packet loss. However, a field called sequence _number is specified in a RTP 
header, which plays a similar role. PCR is used to precisely synchronize the clocks of 
receiver and transmitter in a constant delayed network. This clock synchronization may 
be simplified in other means, (e.g. using the timestamp in RTP header) 

In an MPEG-2 transport stream, elementary streams are usually encapsulated in a 
packetized elementary stream (PES). The PES header carries various rate, timing, and 
data descriptive information, as set by the source encoder. One option is to map an entire 
PES packet directly to a RTP packet to reserve all the information carried in a PES 
header. However, most of the fields in a PES header are optional. The most relevant field 
in a PES header to a broadcasting service is the Presentation Time Stamp (PTS). This 
PTS of MPEG-2 picture or audio frame can be carried in the timestamp field in a RTP 
header. The RTP packets carry the same picture or audio frame should have the same 
timestamp. 

To reduce the overhead of RTP/UDP/1P headers (total 40 bytes), a standard 
compression scheme [5] may be applied. This compression algorithm compresses the 
combined RTP/UDP/IP 40 byte header to a 2 byte when UDP checksum is not sent, 4 
bytes otherwise. 
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